The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Authentication, Authorization, and Accounting (AAA) client/server protocols are used in computer networks to authenticate users or devices, to authorize the use of resources by users or devices, and to generate and store accounting information of how the users or the devices utilize the resources. Under AAA protocols, authentication, authorization and configuration information is typically exchanged between clients and AAA servers in messages that are transported over wired or wireless networks. The AAA servers may provide services over AAA protocols to users and/or devices, so in the paragraphs that follow the description of providing services to users is to be regarded in an illustrative rather than a restrictive sense. Typically, the clients are responsible for receiving information from a user or device, passing the information to an AAA server or servers, and acting on the response that is returned. The AAA servers are responsible for receiving user or device connection requests, authenticating the user or the device, and then returning all configuration information necessary for the client to deliver service to the user or the device.
AAA protocols usually require identifying clients and servers by their network addresses. The communications between the clients and AAA servers are based on these network addresses. Furthermore, most AAA protocols provide mechanisms for securing the communications between clients and servers, such as use of shared secrets, encrypting user names and passwords, challenge-response authentication, and/or public/private key encryption of protocol messages. Invariably however, these security mechanisms are based, or depend tightly, on the network addresses of the clients. This tight coupling of security mechanisms with client network addresses has numerous disadvantages.
One such disadvantage is that AAA protocols do not scale very well for large networks, in part because in order to maintain proper AAA protocol security an AAA server must store and maintain client information. Since the security mechanism is tied to a client network address, the AAA server must maintain at least the client network address of a client in order to be able to securely communicate with the client. For example, in large networks that can accept an arbitrary number of AAA clients, such as wireless networks with multiple access points, an AAA server has to maintain a database of client information for potentially a very large number of clients.
Moreover, in some networks a client may have more than one network address. For example, in a computer network, a network element, e.g. a router, may have several network addresses. Thus, to provide services to this network element over an AAA protocol, an AAA server must maintain separate security information for each network address of the same network element. Furthermore, in large computer networks where the clients usually do not have static network addresses but are assigned network addresses dynamically, it may be practically impossible to employ AAA servers to keep track of all network address changes, while at the same time providing services over a secure AAA protocol.
When network addresses are dynamically assigned to clients, another disadvantage is the significant security risk and/or manual configuration involved in employing AAA protocols to deploy new clients that have not yet been assigned network addresses. The security mechanisms of the AAA protocols usually depend on the client network addresses to provide for secure communications. Using these security mechanisms to deploy clients that do not yet have network addresses usually involves transmission of un-secure or minimally secured messages between clients and AAA servers. Furthermore, there are significant difficulties in using AAA protocols to securely deploy and communicate with an isolated network device that is connected to an established network element but that cannot obtain a network address at all.
One past approach that attempts to address the disadvantage of using AAA protocols to securely deploy new clients is the use of AAA protocols with very weak security. In this approach, all new clients are manually provisioned with the same secret, password, or encryption key, which are used to communicate with the AAA servers during initial client deployment. Another approach attempted in the past is to use the security credentials of an administrator or the security credentials of a trusted intermediary device to deploy new clients. Both of these past approaches, however, introduce new security-related problems. In the first approach, all new clients use the same secret, which, if exposed, will compromise the deployment of all existing and future clients. In the second approach, an administrator or an intermediary device must expressly trust that a new client being deployed is not an imposter, thus shifting a major portion of the security burden from the AAA server to the administrator or the intermediary device.
Several AAA protocols suffer from the above-mentioned disadvantages including the Terminal Access Controller Access Control System (TACACS) protocol and Remote Authentication Dial-In User Service (RADIUS) protocol. The TACACS protocol is a User Datagram Protocol (UDP)-based, access-control protocol described by RFC1492 that was published by the Internet Engineering Task Force (IETF) in July 1993. It provides for exchanging Network Access Server (NAS) information between a network device and a centralized database. The original TACACS implementation used a username/password authentication mechanism in which the username and the password were transmitted in clear text. Newer implementations of TACACS use a challenge-response authentication mechanism for authenticating and authorizing users, and a first-level security mechanism based on the Internet Protocol (IP) addresses of the clients. The first-level security mechanism includes keeping an IP address permit list at the TACACS server, and allowing communications only with IP addresses that are on the list.
RADIUS is a widely used AAA protocol that also uses UDP for communications between RADIUS clients and RADIUS servers. RADIUS is defined in RFC2865 that was published by IETF in June 2000. RADIUS clients and servers are identified by their IP addresses. RADIUS messages are secured by binding a secret to a client IP address. The secret is shared between the client and the server and is never transmitted over the network. The RADIUS protocol employs the shared secret to compute a Message Integrity Check value that is included in RADIUS requests and responses so that the receiver can verify the origin and integrity of a given message.
Both TACACS and RADIUS servers must store client information. The client information includes at least the IP addresses of the client and, in the case of RADIUS, the shared secret. Both TACACS and RADIUS share the disadvantages mentioned above—they do not scale to networks that may potentially include a large number of clients, and there are significant security risks in using these protocols to deploy new clients that have not yet been assigned IP addresses.
Based on the foregoing, there is a clear need for a technique for securing AAA protocol messages that overcomes the disadvantages mentioned above.